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Intellectual Property Rights 
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pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://ipr.etsi.org ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 



This Technical Specification (TS) has been produced by ETSI Technical Committee Electronic Signatures and 
Infrastructures (ESI). 

The present document is part 6, sub-part 2 of a multi-part deliverable. Full details of the entire series can be found in 
part 1 [1]. 



Introduction 

The summarised scope of each part and sub-part can be found in part 1 [1] of this multi-part deliverable. 
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Scope 



The present document specifies requirements for achieving interoperabihty between the Registered Electronic Mail 
systems that are compliant with TS 102 640 (REM henceforth) specification [1] to [5] and systems that are compliant 
with "Business Document Exchange Network service metadata and transport specification" (BUSDOX henceforth) [6] 
to [11]. 

The approach used for this purpose is to define all the necessary mappings between the two specifications taking into 
account also the objective to maintain and preserve the main advantages and positive features present in both the 
realities as pursued in the Technical Specifications. 

The present document is structured as follows: 

• Clause 4: Mapping of terms and definitions. 

• Clause 5: Functional GAP analysis between REM and BUSDOX. 

• Clause 6: Covered Scenarios: REM+BUSDOX to BUSDOX and BUSDOX to REM+BUSDOX. 

• Clause 7: Profile specification for the interaction scenarios defined in clause 6. 



References 



References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the 
reference document (including any amendments) applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are necessary for the application of the present document. 

[1] ETSI TS 102 640-1: "Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail 

(REM); Part 1: Architecture". 

[2] ETSI TS 102 640-2: "Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail 

(REM); Part 2: Data requirements. Formats and Signatures for REM". 

[3] ETSI TS 102 640-3: "Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail 

(REM); Part 3: Information Security Policy Requirements for REM Management Domains". 

[4] ETSI TS 102 640-4: "Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail 

(REM); Part 4: REM-MD Conformance Profiles". 

[5] ETSI TS 102 640-5: "Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail 

(REM); Part 5: REM-MD Interoperability Profiles". 

[6] BUSDOX START: "Secure Trusted Asynchronous Reliable Transport (START) v 1 .0.0 WPS 

2009-12-22". 

[7] BUSDOX METADATA PUB: "Service Metadata Publishing v 1.0.0 WPS 2009-12-23". 

[S] BUSDOX METADATA LOC: "Service Metadata Locator Profile v 1.0.0 WPS 2009-12-21". 

[9] BUSDOX LIME: "Lightweight Message Exchange Profile v 1.0.0 WPS 2009-12-22". 
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[10] BUSDOX PEPPOL: "PEPPOL Identifier Schemes v 1.0.0 WPS 2009-12-23". 

[11] BUSDOX COMMON DEFINITIONS: "Business Document Exchange Network - Common 

Definitions v 1.0.0 WPS 2009-11-27". 

[12] W3C WS-Transfer: "Web Sei-vices Transfer (WS -Transfer)" - W3C Working Draft 

5 August 2010. 

NOTE: Available at http://www.w3.org/TR/2010AVD-ws-transfer-20100S05 . 

[13] W3C WS-Addressing: "Web Services Addressing (WS-Addressing)" - W3C Member Submission 

10 August 2004. 

NOTE: Available at http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040S10 . 

2.2 Informative references 

The following referenced documents are not necessary for the application of the present document but they assist the 
user with regard to a particular subject area. 

[i.l] ETSI TS 102 640-6-1: "Electronic Signatures and Infrastructures (ESI); Registered Electronic 

Mail (REM); Part 6: Interoperabihty Profiles; Sub-part 1: REM-MD UPU PReM InteroperabiUty 
Profile". 

[i.2] ETSI TS 102 640-6-3: "Electronic Signatures and Infrastructures (ESI); Registered Electronic 

Mail (REM); Part 6: Interoperability Profiles; Sub-part 3: REM-MD SOAP Binding Profile". 

[i.3] IETF RFC 5321: "Simple Mail Transfer Protocol". 

[i.4] IETF RFC 5322: "Internet Message Format". 

[i.5] IETF RFC 575 1 : "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message 

Specification". 

[i.6] IETF RFC 39S6: "Uniform Resource Identifier (URI): Generic Syntax". 

[i.7] ISO/IEC 27001:2005: "Information technology — Security techniques — Information security 

management systems — Requirements". 

[i.S] ETSI TS 102 231: "Electronic Signatures and Infrastructures (ESI); Provision of harmonized 

Trust-service status information". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TS 102 640-1 [1] and the following apply: 

REM/BUSDOX Gateway: set of technical and physical components, policies and processes that provide the gateway 
service among REM network and BUSDOX network 

NOTE: A REM/BUSDOX Gateway may be a sub-service/module of a REM-MD or to be separated service. 

Throughout the present document a number of verbal forms are used, whose meaning is defined below. 

• shall, shall not: indicate requirements strictly to be followed in order to conform to the present document and 
from which no deviation is permitted. 

• should, should not: indicate that among several possibilities one is recommended as particularly suitable, 
without mentioning or excluding others, or that a certain course of action is prefeiTed but not necessarily 
required, or that (in the negative form) a certain possibility or course of action is deprecated but not prohibited. 
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• may, need not: indicate a course of action permissible within the limits of the present document. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AP BUSDOX Access Point 

EPR BUSDOX EndPoint Reference 

LC BUSDOX LIME Client 

LIME BUSDOX Lightweight Message Exchange Profile 

SML BUSDOX Service Metadata Locator 

SMP BUSDOX Service Metadata Pubhshing 



IVIapping of terms and definitions 



Business Document Exchange Network (BUSDOX) specifies a document exchange infrastructure. BUSDOX Access 
Points communicate in a peer-to-peer model across the internet to form the BUSDOX infrastructure. 

BUSDOX provides a specification, which may be instantiated in concrete implementations. For example, an instance of 
BUSDOX is the PEPPOL infrastructure, which includes governance models, certificate rules, identifier formats, and 
other profiling. This part is outside BUSDOX specification but included in PEPPOL. 

In Table 1 a mapping among the main terms and definitions used in REM Technical specifications 
TS 102 640-1 [1] to TS 102 640-5 [5], and equivalent terms used in BUSDOX [6] to [11] specifications is provided. An 
empty cell means that the corresponding specification does not define an equivalent term of the one shown in the same 
row and defined in the other specification. 
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Table 1 : Mapping of definitions 



ETSI REM definitions (TS 102 640-1 [1], clause 3.1) 


BUSDOX definitions 11] 


REM-MD 


Access Point (AP) 


Sender's REM-MD 


Source Access Point (SrcAP) 


Recipient's REM-MD 


Destination Access Point (DestAP) 




Secure Trusted Asynchronous Reliable Transport 
(START) 




Lightweight Message Exchange Transport (LIME) 




Lightweight Client or LIME Client (LC) 




Lightweight Profile Access Point (LIME-AP) 




Message Channel (MC) 




Inbound/Outbound Message Channel (InMC/OutMC) 




Endpoint Reference (EPR) 




Channel Identifier (ChannellD) 




Service Metadata Locator service (SML) 




Service Metadata Publisher (SMP) 




Service Metadata Consumer (SMC) 




Participant Identifier (participant! D) 




Document Identifier (documentID) 




Process Identifier (processID) 


certification authority 




information security policy 




Information Security Management System 




long term storage 




message archive 




original message 


Business message 


REM-MD repository 




Registered E-Mail 




REM dispatch 




REM Management Domain 


BUSDOX Access Point 


REM-MD envelope 


SOAP Envelope 


REM-MD evidence 




REM-MD Evidence Provider 




REM-MD Evidence Verifier 




REM-MD Message 


BUSDOX Message 


REM-MD Message Gateway 




REM-MD Message Transfer Agent 




REM-MD Repository Retrieval Interface 




REM-MD Sender Message Submission Interface 


LIME Interface 


REM-MD Third Party Evidence Retrieval Interface 




REM Message Store 




REM Object 




REM Objects Relay Interface 


START Interface 


REM User Agent (REM-UA) 




REM Policy 




REM Policy Domain 




REM Policy Domain Authority 




REM Recipient 


(Recipient) LIME Client 


REM Sender 


(Sender) LIME Client 


REM Third Party 




Signature Creation Server 




Time-Stamping Authority 




Time-Stamp Token 
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5 Functional GAP analysis between REM and 

BUSDOX 

The main differences between the functional aspects of ETSI REM and BUSDOX will be identified in the present 
clause by comparing, when possible, the similar aspects of the two systems under analysis. In particular the following 
aspects will be considered in the GAP REM versus BUSDOX: 

• Main scopes 

• Trust models 

• Formats 

• Evidence 

A mapping between high level functions is identified in Table 2. The attention is concentrated to the boundary functions 
that are involved in the gateway among REM and BUSDOX systems, and to some other remarkable feature providing a 
more general view. 

Table 2: GAP Analysis 



ETSI REM 


BUSDOX 


The main scope of ETSI REM technical specification 
is to provide a reliable transport of messages 
enriched with a full set of evidence for the Sender 
and the Recipients regarding the exchanged 
messages. 


The main purpose of the BUSDOX technical 
specification is to define a messaging infrastructure 
for secure and reliable exchange of electronic 
documents. 


The Trust model of ETSI REM is based on the 
specifications of the Electronic Signatures and 
Infrastructures (ESI) and in particular on the TSL 
(Trusted List of supervised/accredited certification 
service providers in accordance with 
TS 102 231 [i.8]). 


Trust model of BUSDOX is mainly based on the 
Secure Trusted Asynchronous Reliable Transport 
(START) infrastructure that is based on standards like 
SOAP, WS-Addressing [13], WS-Security, 
WS-Transfer [12], WS-ReliableMessaging and SAML. 


The format of the exchanged messages in the REM 
model to which the present document refers is based 
on the MIME standard (RFC 5751 [1.5]) enriched with 
a set of typical Headers of the SMTP (RFC 5321 [1.3]) 
messaging protocol. 


The format of exchanged messages in BUSDOX 
model is based on the standards used in the 
protocols (mainly SOAP, WS-Transfer [12]). 


The evidence generated in a REM system is 
composed of specific signed information, created 
within a REM-IVID, which proves that a certain event 
has occurred at a certain time. 


BUSDOX does not have an analogue concept to the 
REM Evidence anyway, as indicated in the next 
clauses of the present document, the interaction with 
REM gives the possibility to have some evidence for 
both REM and BUSDOX users. 



Covered Scenarios 



In the present document two scenarios will be covered: 

• REM+BUSDOX to pure BUSDOX - In this scenario the information flows from the REM network to the 
BUSDOX network. 

• Pure BUSDOX to REM+BUSDOX - In this scenario the information flows from BUSDOX network to the 
REM network. 

In both cases the contact points between the two networks is a new special network element acting as the gateway 
(REM/BUSDOX Gateway henceforth) among REM and BUSDOX. 
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The profile to use between the REM Sender and the REM/BUSDOX Gateway (through the REM-MD and the 
REM-UA) shaU be the "REM-MD InteroperabiHty Profiles" defined in TS 102 640-5 [5] REM technical specification. 
To simplify the description the terms REM Sender and REM Recipient shall be used in the present document without 
an explicit mention of the REM-UA role that is always present in the middle to such type of interactions. Similarly 
REM "Senders" and "Recipients" are generic terms that shall mean any entity like Process Applications, human users 
without any other explicit mention. 

6.1 REM+BUSDOX to pure BUSDOX 

An interesting scenario may take place when one of the endpoints implements the REM stack. The picture below shows 
a REMh-BUSDOX sender communicating with a pure BUSDOX recipient through the REM/BUSDOX Gateway 
functions specified in the present document. 




user 



Figure 1 

REM would normally consider this case in the same way as sending a message to a non-REM system (like ordinary 
mail). However, trust is established at the AP level and a proof of relay of the message is provided at the AP level, in 
the form of a wsse:SignatureConfirmation. 

This proof shall be managed by the Sender's REM/BUSDOX Gateway in order to produce a set of evidence as defined 
in clause 7.2.6. Note that some of this is somehow weaker than a RelayToREMMDAcceptanceRejection evidence, 
which it is produced (and signed) by the Recipient's REM-MD. 



6.2 



Pure BUSDOX to REM+BUSDOX 



Similarly to the previous scenario defined in clause 6.1, the following picture shows the flow of a pure BUSDOX 
sender communicating with a REMh-BUSDOX recipient. 
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Figure 2 

REM would normally consider this case in the same way as receiving a message from a non-REM system (like ordinary 
mail), since no REM envelope is arriving to the Recipient's side. But, the introduction of the REM/BUSDOX Gateway 
should produce the necessary information and formats to submit to the REM system and the REM Evidence feedback 
for the BUSDOX system as defined in clause 7.3.4. For this purpose the REM/BUSDOX Gateway may also leverage 
the trust established at the AP level and some information like the proof of relay of the message (in the form of a 
wsse:Signature). This proof should be used by the Recipient's REM/BUSDOX Gateway to produce the evidence of 
Submission of the message to the REM network. Note that this is somehow weaker than a 
SubmissionAcceptanceRejection evidence, which it is produced (and signed) by the Sender's REM-MD. 



Profiles specifications 



The present clause contains specifications that cover the two interaction scenarios described in clause 6. 
Clause 7.1 and its clauses contain specifications that are used in both scenarios. 

Clause 7.2 and its clauses contain specifications that are used in the REM+BUSDOX to pure BUSDOX scenario. 
Clause 7.3 and its clauses contain specifications that are used in the pure BUSDOX to REM+BUSDOX scenario. 



7.1 Common specifications 



7.1.1 



Identifiers 



The current clause defines new identifiers schemes for the already identified scenarios. It also defines new identifiers to 
be used within them. These identifiers are used by the full identification of the participants, the documents and the 
processes. 
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7.1 .1 .1 REM-MD Participant Identifiers 

The current clause provides specifications for the participant identifiers that are required in the REM-MD - BUSDOX 
scenario. 

In the REM-MD - BUSDOX scenario the participants that need a BUSDOX participant identifier are: 

1) The Sender's REM-MD, when it is the actual participant in the BUSDOX instantiation. 

2) The REM Sender or the REM Recipient, when the BUSDOX knowledge it is extended at REM 
Sender/Recipient level. 

3) The BUSDOX participant who is the purported Recipient (BUSDOX recipient henceforth) of the message 
submitted by the REM Sender. This is a regular BUSDOX participant served by one Access Point as remarked 
in clause 6.1, and in consequence she operates with her own Participant Identifier, whose structure and 
semantics are defined in the corresponding BUSDOX instantiation. 

The present profile defines a new scheme for participant identifiers in BUSDOX instantiations that are REM-MDs or 
REM Senders/Recipients. The details of the new scheme are shown in the paragraphs below. 

The domain value shall be 'etsi'. 

The subject area value shall be 'actorid'. 

The value of the scheme identifier type shall be 'tsl02640pis' (i.e. Technical Specification 102640 Participant Identifier 
Scheme). 

So the Scheme Identifier of the participant identifier in REM-MD - BUSDOX scenario shall be: 

"etsi-actorid-tsl02640pis" 

The definition of aforementioned Scheme fully identifies the specification of the participant identifier format. 

The participant identifier format shall be composed of two parts, namely identifier type and identifier value, which 
shall follow the following rules: 

1) The identifier type part shall be 'rfc5322' (this identifier refers to the RFC 5322 [i.4] Internet Message Format 
standard). 

2) The identifier value shall be the email address of the participant. 

3) The two parts shall be concatenated by the ':' string. 

This is a non-normative example, of the participant identifier corresponding to a purported REM Sender whose email 
address is 'emailaddr-one-rem-md-sender@one-rem-md.domain.com': 

etsi-actorid-tsl02640pis::rfc5322:emailaddr-one-rem-md-sender@one-rem-md. domain. com 
It obeys to the standard rules defined in "BUSDOX COMMON DEFINITIONS" [11] that are: 

Participant id = {identifier scheme}:: {id} 

id = {type identifier}: {participant identifier value} 

The first part (the scheme identifier) and also the "type identifier" part are fixed for the purpose of the present document 
and should be entirely managed in the BUSDOX Environment and by the REM/BUSDOX Gateway). 

The rationale of such definition is that when the flow of the information is at BUSDOX side the entire Participant 
Identifier shall be used. When the flow of the information is at REM-MD (or at REM/BUSDOX Gateway) side the 
email address part of the participant identifier shall be used: the Internet domain part (to the right of '@') shall identify 
the REM-MD and the local part (to the left of '@') shall identify either the REM Sender or the REM Recipient 
(according to the scenario). 

All the percent encoding form defined in "BUSDOX COMMON DEFINITIONS" [11] shall be used for the participant 
identifier when it is used in some URL. 
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7.1 .1 .2 Document Identifiers for REM-MDs 

The present profile defines the new document identifier scheme. The details of the new scheme are shown in the 
paragraphs below. 

The domain value shall be 'etsi'. 

The subject area value shall be 'docid'. 

The value of the preferred scheme identifier type shall be 'tsl02640dis' (i.e. Technical Specification 102640 Document 
Identifier Scheme). 

So the Scheme Identifier of the Document Identifier in REM-MD - BUSDOX scenario shall be: 

"etsi-docid-tsl02640dis" 

The definition of aforementioned Scheme fully identifies the specification of the document identifier format. 

The document identifier format shall be composed of two parts, namely identifier type and identifier value, which shall 
follow the following rules: 

1 ) Document Id = { identifier scheme } : : { id } . 

2) { id } = { type identifier } : { document identifier value } . 

3) The identifier type part shall be 'rfc5751' (this identifier refers to the RFC 5751 [i.5] MIME standard). 

4) The identifier value shall be 'mime'. 

5) The two parts scheme and id shall be concatenated by the '::' string. 

6) The two parts type and value shall be concatenated by the ':' string. 

So, the full Document Identifier to use during the interchanges, applying the present profile, shall be in consequence: 
'etsi-docid-tsl02640dis::rfc5751:mime'. 

In particular cases outside the scope of the present technical specification (e.g. agreements among REM/BUSDOX 
Gateway providers and BUSDOX users) other type of documents may be accepted by REM/BUSDOX Gateway 
provided that they are enveloped and forwarded to REM-MD (and in consequence delivered to REM Recipients), 
according to the formats specified in TS 102 640-5 [5]. In such cases the value of the scheme identifier type should be 
'tsl02640adis' (i.e. Technical Specification 102640 Any Document Identifier Scheme) or may also be any of the types 
associated with the document identifier schemes valid in the BUSDOX instantiations. In the first case the full 
identification string shall be: 

"etsi-docid-tsl02640adis" 

and the Document Identifier shall assume the following format: 

1) The identifier type part shall be absent. 

2) The identifier value shall be 'anydocumenttype'. 

The full Document Identifier shall be in this case: 'etsi-docid-tsl02640adis::anydocumenttype'. 

Interchangers may also, according to this profile, use any other document identifier as long as that document identifier 
is aligned with one of the document identifier schemes defined in the BUSDOX instance where the purported Recipient 
is subscribed. Such practice should be transparent to the REM Senders or REM Recipients (according to the scenario) 
and should be subject to particular agreements involving the implementation/configuration of the REM/BUSDOX 
Gateway. 

7.1 .1 .3 Process Identifiers for REM-MDs 

The present profile does not define any new process identifier scheme. 

Sender subscribed to REM-MD may use the process scheme identifier specified in "BUSDOX COMMON 
DEFINITIONS" [11] when the document sent is not sent under any named process. 
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Sender may also, according to this profile, use any other process identifier as long as that process identifier is aligned 
with one of the process identifier schemes defined in the BUSDOX instance where the purported Recipient is 
subscribed. 

7.2 REM+BUSDOX to pure BUSDOX 

The present clause provides specifications for the REM+BUSDOX to pure BUSDOX scenario. In this scenario a 
normal REM-MD user (the REM Sender) needs to send a REM-MD message to a pure BUSDOX user (the Recipient). 
The Recipient shall be identified by the Sender using her BUSDOX instantiation participant identifier. The Recipient 
shall be registered to the SMP service using the same BUSDOX instantiation participant identifier exchanged with the 
Sender. It is out of the scope of the present document to specify how the Sender gains access to this identifier. 

Below follows a detailed description of the interactions between the different entities that collaborate in ensuring a 
successful exchange of messages between the Sender subscribed to a REM-MD and the Recipient who is a BUSDOX 
instantiation participant. A reference to the clause of the present document that specifies requirements for the 
corresponding interaction is included: 

1) The Sender composes a regular electronic mail as specified in clause 7.2.1 of the present document. After this 
step, the Sender's original message is stored in the REM-MD spool areas. 

2) Before forwards the Sender's payload to the BUSDOX Access Point, the REM/BUSDOX Gateway shall 
implement the discovery process of the metadata required for ensuring a successful transfer of the message, as 
specified in the BUSDOX Service Metadata Locator Profile (SML henceforth) [8] and further profiled in 
clause 7.2.2 of the present document. 

3) The Sender's REM-MD then gains access to the Service Metadata Publisher that contains the metadata of the 
purported Recipient, as specified in the BUSDOX Service Metadata Publishing (SMP henceforth) [7] protocol 
and further profiled in clause 7.2.2.2 of the present document. 

4) The Sender's REM-MD shall act as a regular BUSDOX instantiation participant (on behalf of the REM Sender 
and through a REM/BUSDOX Gateway) and shall interact with a BUSDOX Access Point. This interaction 
shall be performed according to the Lightweight Message Exchange Profile (LIME henceforth) [9] and further 
profiled in clause 7.2.3 of the present document. 

5) The REM-MD's Access Point then takes the Sender's payload as received from the REM-MD and forwards it 
to the Access Point of the BUSDOX instantiation purported Recipient using the Secure Trusted Asynchronous 
Reliable Transport (START henceforth) [6]. 

6) Once the message is got by the Recipient's Access Point, the purported Recipient may gain access to the 
message using any BUSDOX supported access protocol (for example the LIME access protocol). 



7.2.1 Sender's original message profile 



The present document defines four new extra MIME headers for the electronic mail message sent by the Sender to her 
REM-MD in this scenario. 

X-REM-Busdox-recipientld. The Sender's REM-UA should include this extra header in the electronic mail message. Its 
value shall contain the full participant identifier of the BUSDOX instantiation purported Recipient of the message. 

X-REM-Busdox-senderld. The Sender's REM-UA should include this extra header in the electronic mail message to 
allow the reply to the message sent. Its value shall contain the full participant identifier of the REM Sender of the 
message. In Figure 3 there is a non-normative example of this flow. 

In case of particular agreements with the Sender the REM/BUSDOX Gateway providers may compose the participant 
identifiers of the Recipient and the Sender (to use in the LIME envelope) using part of the email addresses specified by 
the Sender and some other information part of the agreement. In such case shall not be mandatory for the Sender to 
specify the aforementioned headers and shall not be mandatory for the Sender to be registered to SMP with a specific 
participantlD. Always in this case only the REM/BUSDOX Gateway shall have a participantID and shall be registered 
on SMP. In Figure 4 there is a non-normative example of these flows. 
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X-REM-Busdox-docType. The Sender's REM-UA may include this extra header in the electronic mail message. When 
present, its value shall contain a document identifier as specified in clause 7.1.1.2 (and, in case of particular 
agreements, it is aligned with one some document identifier defined in BUSDOX). It is out of the scope of the present 
document to deal with the means by which the Sender may gain access to this value and how it can be managed. 

X-REM-Busdox-processId. The Sender's REM-UA may include this extra header in the electronic mail message. When 
present, its value shall contain a process identifier aligned with one of the process identifier schemes defined in the 
BUSDOX instance where the purported Recipient is subscribed. It is out of the scope of the present document to deal 
with the means by which the Sender may gain access to this value and how it can be managed. 

The "To:" header value shall be composed with an email address according to some agreement between the Sender and 
the REM/BUSDOX Gateway providers. 

These are non-normative examples explaining a possible mapping among addresses (subject to the agreements between 
the REM Sender (and the REM/BUSDOX Gateway providers): 

The REM Sender may specify as virtual recipient a particular mailbox (one of a set of 1..N gateway mailboxes for 
scalability purposes) of the REM/BUSDOX Gateway. E.g.: 

busdoxgateway 1 @ rem-md-gateway-domain' 

In such case, the entire Recipient's participantID shall be managed by the REM/BUSDOX Gateway using the X-REM- 
Busdox-recipientld header specified by the Sender. In Figure 3 there is an example of this flow. 



REM Sender 



BUSDOX Recipient 




IVlllVIE 
IVlessage 



The REM-MD Gateway submits the entire REM-MD Message as MiME using, as recipient, the participantID specified by 
the Sender in the specific Header. In this example address; busdox-actorid-upis::0010:5798000000001 



Standard MIME message sent, for exampie, to the foilowing REM-M D Gateway's address specified as recipient: busdoxgateway1@rem-md-gateway-domain 

The MilVlE enveiope contains the reai recipient's ParticipantiD as a specific Header. For exampie: 

X-REM-Busdox-recipientld:busdox-actorid-upis::0010:5798000000001 

X-REM-Busdox-senderld: etsi-actorid-ts102640pis::rfc5322:emailaddr-one-rem-nid-sender@one-rem-nid.domain.com 



Figure 3 



Alternatively, the REM Sender may use the variable part of the Recipient's participantID (the value part) to compose 
the "To:" fields of the regular email to send. The domain part of this address should be a managed domain of the 
REM/BUSDOX Gateway (and so be subject to an agreement between the Sender and the REM/BUSDOX Gateway 
providers). 

E.g. if the Participant Identifier of the BUSDOX recipient user is: 

'busdox-actorid-upis::0010:5798000000001' 

the REM Sender shall compose a regular email having the following "To:" email address: 

'5798000000001@rem-md-gateway-domain' 

whereas, the fixed parts of the Recipient's participantID ('busdox-actorid-upis::0010:') shall be fully managed by the 
REM/BUSDOX Gateway. 

Other mappings are possible for the "To:" MIME header and subject to particular agreements with REM/BUSDOX 
Gateway providers. E.g. 



'5798000000001@0()10.rem-md-gateway-domain' 

In Figure 4 there is an example of this flow. 
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REM Sender 



BUSDOX Recipient 




y MIME 
Message 



The REM-MD Gateway submits the entire REIW-IVID IWessage as IVIIIVIE using, as recipient, the variable part of participant! D 

specified by the Sender in the To: field adding the fixed part relevant to the schema (and the Global Location when 

necessary). In this example the recipient's participantID it will become: 

Similarly, the REM-MD Gateway uses as sender's participantID the email address of the sender (from: or reply-to: headers of 

the MIME). In this example the sender's parlicipantID will become the participantID of the REM-MD Gateway: 

etsi-actorid-ts102G40pis::rfc5322:busdoxgateway1@rem-md-gateway-domain 



Standard MIME message sent, for example, to the following REM-MD Gateway's address specified as recipient (and 

including the recipient's participantID value): 

No special X-header for full recipient's participantID is needed in this case that shall be completed as required by the 

REM-MD Gateway. 

For flexibility and scalability reasons, a variant to this example for the sender is to specify as gateway sub-domain the 

Global Location Number 0010 obtaining the recipient's MIME Header: 

To: 5798000000001@0010.rem-md-gateway-dornain 

In order to allow a reply to this message using the same schema (REM user not registered on SMP, but only REM-MD 

gateway registered to SMP with 1..N Gateway mailboxes), the sender will specify the following MIME headers: 

From: busdoxgateway1@rem-md-gateway-domain 

Reply-to: busdoxgateway1@rem-md-gateway-domain 



Figure 4 



In this case, other than the REM/BUSDOX Gateway managed domain there is a sub-domain (0010) corresponding to 
the Recipient's participantID type. This could give some more indication to the REM/BUSDOX Gateway for the 
composing of the final BUSDOX recipient participantID and for the routing 

Furthermore, the Recipient may answer to the Sender using the participantID set by the REM/BUSDOX Gateway as 
etsi-actorid-tsl02640pis::rfc5322:busdoxgatewayl@rem-md-gateway-domain. 

It is important to outline that in this flow, is not necessary the REM Sender to be registered to SMP. 

Some detailed example of this opposite (answer/reply) flow is defined in Figure 6. 

The four new REM extra headers shall be preserved also in the external REM-MD envelope as defined in clause 7.2.5. 

No further requirements are specified for the Sender's original message. 

At the arrival of any electronic mail arrived from one of its subscribers having a previous agreed email address as value 
in the "To" header and/or the X-REM-Busdox-recipientId extra header the REM/BUSDOX Gateway shall process it as 
specified in the present document. 



7.2.2 SML and SMP profiling 



The submission of a message through an AP requires the REM/BUSDOX Gateway to compile some parameters such as 
the identity and other Recipient's properties. 

As established in the Service Metadata Publishing (SMP) Technical Specification [7], the discovery of the necessary 
parameters to transmit a message, using the BUSDOX service, happens through the lookup interface to the Service 
Metadata PubUsher (SMP). 

The SMP access address is provided through the Service Metadata Locator (SML) specification [8] that is a formalism 
that allows to compose a URL based on standard DNS names. 

Every "participant" of the BUSDOX system (and therefore also every particular Recipient like a BUSDOX user) is 
recorded to one and only one SMP. 

Under these considerations the necessary sequence of steps that the Sender's REM/BUSDOX Gateway needs to 
implement shall be the following: 

• The REM/BUSDOX Gateway (client of BUSDOX AP) composes the access URL, to the SML in order to 
discover the access URL of the SMP provider for the specific Recipient, according to the Service Metadata 
Locator (SML) specification [8]. 
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• The REM-MD requires to SMP the Service Metadata relevant to the Recipient of the REM-MD message using 
the URL composed according to the previous point. 

• The REM-MD, using the Service Metadata received from the SMP answer, compiles the correct BUSDOX 
message to submit to the AP. 

Clauses below specify in detail how the aforementioned steps shall be performed. 

7.2.2.1 URL to access to SMP composition 

As specified in Service Metadata Locator (SML) specification [8], the format of the URL for the lookup to SMP has the 
following syntax: 

http://<hash over recipient's participantID>.<schemeID>.<SML domain>/<recipient's 
participantID>/services/<documentType> 

Where: 

• The HASH of the Recipient's participantID is composed of the string "B-" followed by the MD5 hash of the 
participantID (the recipientID in this case). The purported Recipient's participant identifier shall be extracted 
by the REM/BUSDOX Gateway from the Sender's original message extra header X-REM-Busdox-recipientId 
(or in any of the agreed method as described in clause 7.2.1). 

• The schemelD shall be the scheme under which the Recipient's participantID has been generated . Its value 
shall be extracted by the REM/BUSDOX Gateway from the Sender's original message extra header X-REM- 
Busdox-recipientld (or in any of the agreed method as described in clause 7.2.1). 

• The SML internet domain is a fixed starting domain that may be configured at start-up time in the 
REM/BUSDOX Gateway. It is out of the scope of the present document to specify how the REM/BUSDOX 
Gateway may gain access to this information. 

• Concerning the document type, if the Sender's original message does not contain the extra header X-REM- 
Busdox-docType, then the document identifier defined in clause 7.LL2 shall be used. Otherwise, the 
document type identifier contained in that field shall be used in the URL. It is out of the scope of the present 
document to deal with the means by which the Sender may gain access to the document types that the 
Recipient may deal with. 

The present document does not provide further profiling of BUSDOX Service Metadata Locator (SML) 
specification [8]. 
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This is a non-normative example that shows the composition of the URL to access to SMP. 

To send a message from a REM Sender to a BUSDOX recipient identified by the following Participant Identifier 

busdox-actorid-upis : : 0010: 5798000000001 

the REM/BUSDOX Gateway needs to compose the URL to access to SMP with the following format: 

http://<hash over recipientID> . <schemeID> . <SML domain>/<recipientID>/services/<documentType> 

using the following fields: 

<hash Recipient's participantID type/value part> = "B- "md5 { "0010 : 5798000000001" ) = "B- 
b9a942eecd58557d2739a06eb2c07fal" 

<schemeID> = "busdox-actorid-upis" 

<SML domain> = "serviceMetadata. eu" {This is an example for SML internet domain address configured 
in the REM/BUSDOX Gateway and obtained during the registration of the particular REM-MD as 
participant of a BUSDOX environment) 

<full Recipient's participantID> = "busdox-actorid-upis :: 0010 : 5798000000001" {Full scheme-id + 
Type/Val) 

<Recipient's participantID> = "0010:5798000000001" {Type/Val) 

<documentType> = "etsi-docid-tsl02640dis : : rf c5751 :mime" 

SO one of the URL that REM/BUSDOX Gateway may use for the SMP discovery, for this example is: 

http : //B-b9a942eecd58557d2739a06eb2c07f al .busdox-actorid-upis . serviceMetadata . eu/busdoxdomain. eu/ 
busdox-actorid-upis : : 010 : 5 798000000 01/services/etsi-docid-tsl02 64 0dis : :rfc5 751 :mime 

Due to reserved words the URL above needs to be percent encoded to be compliant with the specification "Uniform 
Resource Identifier (URI): Generic Syntax" (RFC 3986 [i.6]), as required in the Service Metadata Publishing Technical 
Specification [7] (where a full description of discovery process may be found), and it becomes: 

http : //B-b9a942eecd5 85 57d2 73 9a0 6eb2c0 7f al .busdox-actorid-upis . serviceMetadata . eu/busdoxdomain. eu/ 
busdox-actorid-upis%3A%3A0010%3A5798000000001/services/etsi-docid-tsl02640dis%3A%3Arfc5751%3Amime 

7.2.2.2 Service Metadata Retrieval from SMP 

The present document profiles a new type of contents for the Servicelnformation element specified in SMP Technical 
Specification [7], namely the one that associates the BUSDOX instantiation participant identifier of the purported 
Recipient with the document type identifier defined in clause 7.1.1.2. 

Table 3 specifies the contents of such new Servicelnformation element. 
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Table 3: Metadata contents 



Element/attribute 


Mandatory/Optional 


Number of 
occurrences 


Additional Requirements 


Document Identifier 


M 


1 


The preferred document identifier profiled 

to be used in REM - BUSDOX context 

shall be the following: 

'rfc5751 :mime' 

In such case the scheme attribute value 

shall be: 

'etsi-docid-ts102640dis' 

In cases of particular agreements 

implemented at REM/BUSDOX Gateway 

level, the document identifier should be: 

'anydocumenttype' 

In such case the scheme attribute value 

shall be: 

'etsi-docid-ts102640adis' 

Always under particular agreements 

implemented at REM/BUSDOX Gateway 

level the document identifier may be any 

of the values aligned with the document 

identifier schemes valid in the BUSDOX 

instantiation with a relevant value 

Further details are defined in 

clause 7.1.1.2 


Document Identifier/ 
©scheme 


M 


1 


The preferred scheme attribute value shall 

be: 

'etsi-docid-ts102640dis' 

It may also be any of the values that 

identify a document identifier scheme valid 

in the BUSDOX instantiation under the 

conditions expressed in clause 7.1 .1 .2. 

If the value 'etsi-docid-ts102640dis' is 

present in this attribute, the 

Documentldentifier element value shall be 

'rfc5751 :mime' 



The present document does not impose other additional requirements to the Document Identifier elements profiled in 
Table 3. 



7.2.2.3 



BUSDOX Headers and REM Headers/Metadata 



One of the tasks of the REM/BUSDOX Gateway is to fill the minimum set of BUSDOX Headers starting from the 
information present in the REM-MD message coming from the Sender and other data owned at REM/BUSDOX 
Gateway level. 

The mandatory headers to evaluate as specified in the section 4.2 of BUSDOX LIME Technical Specification [9] are 
listed in Table 4. 
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Table 4: Metadata Headers 



Header 


Mandatory/Optional 


Number of 
occurrences 


Additional Requirements 


Sender Identifier 


M 


1 


This header shall be compiled according 
to the specifications of clause 7.1 .1 .1 
using the email address of the Sender as 
parameter. 


Recipient Identifier 


M 


1 


This header shall be compiled according 
to the specifications of clause 7.1 .1 .1 
using the participant identifier of the 
Recipient as parameter. 
In case of multi-recipient email, coming 
from the REI\/1 Sender, this process shall 
be iterated for each Recipient (To: or Cc:) 
producing a BUSDOX message for each 
Recipient. Each iteration shall be a full 
BUSDOX sending phase including 
CREATE and PUT (it shall be a BUSDOX 
"Entry" of the PageLlst during the GET 
Phase). 


Document Identifier 


M 


1 


This header shall be compiled according 
to the specifications of clause 7.1 .1 .2 
using the document identifier of the 
Recipient as parameter. 


Process Identifier 


M 


1 


This header shall be compiled according 
to the specifications of clause 7.1 .1 .3 
using the process identifier of the 
Recipient as parameter. 


Messageldentif ier 


M 


1 


This header shall be compiled according 
to the specifications of the section 4.2.3 of 
BUSDOX LIME Technical Specification 
[9]. For each resend of the message for 
iterations due to errors such value shall 
be maintained always the same to the 
Messageldentifier returned back from AP 
during the CREATE phase. 
For each iteration of sending message due 
to multi-recipient headers present in the 
Sender's MIME message, a new cycle 
CREATE/PUT shall be performed and so 
a new Messageldentifier shall be used 
(that returned back from the CREATE 
response). 


Channel Identifier 


M 


1 


This header shall be compiled according 
to the specifications of the section 4.3 of 
BUSDOX LIME Technical Specification 
[9]. The method used by the 
REM/BUSDOX Gateway to obtain the 
value of this header is out of scope. It may 
be configured in the set up phase of 
REM/BUSDOX Gateway. 



7.2.3 LIME Profile 

The REM/BUSDOX Gateway shall acts like a LIME Client (LC) of a LIME-Enabled AP as specified in BUSDOX 
LIME Technical Specification [9] using a Message Channel (that is a WS-Transfer endpoint of the AP and is identified 
by an EndpointRe fere nee). 

A flow like that described in the Figure I of BUSDOX LIME Technical Specification [9] shall be implemented. The 
REM/BUSDOX Gateway shall be the LIME Client (LC). 

Two channels (Inbound and Outbound) should be implemented as defined in section 4. 1 of BUSDOX LIME Technical 
Specification [9] and secured as defined in section 4.3.1 of BUSDOX LIME Technical Specification [9]. 
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In the messages submitted by REM/BUSDOX Gateway to the AP the SAML attribute for common authentication 
assurance-level shall be included as for specification defined in the section 4.4.3 of BUSDOX LIME Technical 
Specification [9] and its value shall be "urn:eu:busdox:attribute:X" where X is a integer parameter in the interval 1..4. 
The exact value to use for the assurance-level is outside the scope of the present technical specification (e.g. at least the 
minimum level recovered as Metadata from SMP queries or special agreements among REM/BUSDOX Gateway 
providers and BUSDOX providers). 

7.2.4 BUSDOX message composition 

Once the addressing mapping are resolved (Participant/Document/Process Identifiers are available and the 
EndpointReference EPR is returned back from SMP), the REM/BUSDOX Gateway shall envelope the Sender's payload 
to a BUSDOX message and it shall be submitted to the Sender's REM-MD AP as indicated in clause 7.2.3. 

The enveloping of the Sender's message is performed according to the specifications BUSDOX LIME Technical 
Specification [9] inside a SOAP 1.1 body container and using the WS-Transfer specification [12] to access to the 
submission channel (AP endpoint). 

In this specific scenario, the REM/BUSDOX Gateway shall send the entire MIME envelope constituent the REM-MD 
message. This entire MIME envelope shall be the new payload of the BUSDOX delivery to send to the BUSDOX 
recipient. This choice allows to maintain attached together the Evidence (XML attachment to the REM-MD message) 
and the original Sender's MIME payload. 

The non-normative examples of Figure 3 and Figure 4 shows how the REM/BUSDOX Gateway might send the entire 
REM-MD message to the AP as payload of the BUSDOX message for the final Recipient. Further details of the 
composition of a REM-MD message can be found in TS 102 640-2 [2] and TS 102 640-5 [5]. 



7.2.5 Generating REM-MD message 

As defined in previous clauses the REM-MD messages shall be generated only at REM-MD level. To perform this 
operation the REM-MD shall have in input a standard MIME email message like that produced by usual email clients. 
This is the Sender's payload that shall be preserved by the entire transport path up to the Recipient. In some case 
defined in the previous clauses this MIME message may contain some new extra header defined in clause 7.2.1 with 
information like sender/recipient participantID, documentID and processID. It is out of the scope of the present 
document to specify how these headers are added to the MIME message submitted by the Sender. 

Any REM-MD that receives a MIME message from any REM-MD chent apphcation (in the present TS a REM-MD 
client application may be either a Sender's REM-UA or the REM/BUSDOX Gateway) containing the new four REM 
extra headers defined in clause 7.2.1 shall preserve such headers copying them also in the external REM-MD Envelope. 

The non-normative examples of Figure 3 and Figure 4 shows how the REM-MD client applications (in the present TS a 
REM-MD client application may be either a Sender's REM-UA or the REM/BUSDOX Gateway) always send to the 
REM-MD a input payload in MIME format. 

7.2.6 Evidence 

In this scenario it is possible to build, at REM-MD level, some of the evidence that the normal REM flow may produce. 
According to the elements provided at BUSDOX level and the REM TS, the following evidence shall be provided: 

Table 5: Evidence types list for REM-BUSDOX scenario 



Event and REM-MD Evidence 
(TS 102 640-1 [1], clause 6.1) 


REM-MD Evidence 
(TS 102 640-2 [2], clause 5.1) 


6.2.1 Event A.1 - S-REM-MD Acceptance 


5.1 .1 SubmissionAcceptanceRejection 


6.2.1 Event A.2 - S-REM-MD Rejection 


6.2.2 Event B.I - R-REM-MD Acceptance 


5.1 .2 Relay ToREMMDAcceptanceRejection 


6.2.2 Event B.2 - R-REM-MD Rejection 


6.2.2 Event B.3 - Expiration of time to deliver to R-REM-MD 


5.1.3 RelayloREMMDFailure 


6.2.3 Event C.I - REM Object Delivery 


5.1 .4 DeliveryNonDeliveryToRecipient 


6.2.3 Event C.2 - Non delivery within a given retention period 


6.2.3 Event D.I - REM-MD Message Delivery 


6.2.3 Event D.2 - Expiration of time to deliver notification 
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Since the first evidence, SubmissionAcceptanceRejection, is generated in REM environment it shall be maintained as it 
is in a REM pure environment. 

The second evidence, RelayToREMMDAcceptanceRejection, shall be generated by the Sender's REM/BUSDOX 
Gateway whenever a message is successfully conveyed fi^om the Sender's AP to the Recipient's AP. The physical event 
that provokes the generation of the evidence is given by the result of the relay operation from the Sender's AP to the 
receiver's AP. If the PUT operation of the outbound LIME interaction returns a positive response, this is a proof-of- 
delivery and so the REM/BUSDOX Gateway shall generate a positive Relay ToREMMDAcceptanceRejection evidence 
for the Sender's REM-MD and a positive DeliveryNonDeliveryToRecipient evidence for the Sender. 

In case of a permanent failure on PUT operation the REM/BUSDOX Gateway shall generate a negative 
RelayToREMMDAcceptanceRejection evidence for the Sender's REM-MD. 

In case of repeated temporary failures on PUT operation (according to a configured number of times) the 
REM/BUSDOX Gateway shall generate a RelayToREMMDFailure evidence for the Sender. 

In both the two cases of failure above the REM/BUSDOX Gateway shall generate a negative 
DeliveryNonDeliveryToRecipient evidence for the Sender. 

7.3 BUSDOX to REM-MD+BUSDOX 

In this scenario a normal BUSDOX user (the Sender) needs to send a generic BUSDOX message to a REM-MD user 
(the REM Recipient). The Recipient shall be identified by the Sender using a conventional e-mail address inserted in a 
BUSDOX context becoming a real participant identifier, as specified in clause 7.1.1.1. It is out of the scope of the 
present document to specify how the Sender gains access to this identifier. 

Composing the envelope for the intended Recipient, the REM/BUSDOX Gateway shall compile the reply-to MIME 
header with one of own gateway addresses and the X-REM-Busdox-senderld with the real BUSDOX Sender's 
participant identifier in order to allow the REM Recipient to eventually answer to the received message to the correct 
BUSDOX address. Figure 5 shows a non-normative example of this flow. 

The back flow of answer/reply to the received message shall be one of those described in clause 7.2 having the actual 
REM Recipient with a role of Sender and vice versa the actual BUSDOX sender with a role of Recipient. 

Another possibility is to specify a participant identifier of the REM/BUSDOX Gateway as first hop and further 
addresses the Recipient through an email address specified in the message to send that, in this case, shall be a MIME 
message and shall be conveyed between Sender's AP and REM/BUSDOX Gateway's AP as a normal BUSDOX 
document. The MIME message shall have the "To:" header set to the REM email address of the Recipient. To allow the 
REM Recipient to eventually answer to the received message the Sender should also compile the From:/Reply-to: 
MIME headers using a method of those described in clause 7.2 but reversing the roles Sender/Recipient. 

The pure BUSDOX envelope (containing the MIME message as Sender's payload) shall have the Recipient's 
participantID set to a BUSDOX address of the REM/BUSDOX Gateway (that acts as a registered LIME Client of 
BUSDOX network) and the Sender's participantID set to the BUSDOX Sender's address. These last two participantID 
should also be set, respectively as X-REM-Busdox-recipientId and X-REM-Busdox-senderld MIME headers, in the 
MIME payload specified by the Sender. 

In case of particular agreements with the Sender the REM/BUSDOX Gateway providers may add these two participant 
identifiers to the MIME payload using the values present in the incoming pure BUSDOX external envelope. In such 
case shall not be mandatory for the Sender to specify the aforementioned MIME headers. 

The REM/BUSDOX Gateway shall submit to the intended Recipient specified in the "To:" header any MIME message 
coming from BUSDOX Network to a REM/BUSDOX Gateway address. Figure 6 shows a non-normative example of 
this flow. 

In this scenario the Recipient's REM/BUSDOX Gateway shall be registered to the SMP service using a set of 
participant identifier (for scalability purposes). These participant identifiers are associated to (composed of) a list of 
1..N conventional e-mail addresses handled in Recipient's REM-MD own environment for the REM/BUSDOX 
Gateway functions. In particular, the domain addresses used by the Sender to identify the REM/BUSDOX Gateway 
need to be handled (and also registered in SMP as "managed" participantID) by the Recipient's REM-MD. 
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These are non-normative examples explaining a possible mapping and flows from BUSDOX network and REM 
network: 

The BUSDOX sender needs to send a generic (not necessarily MIME) BUSDOX message to a REM Recipient. For this 
purpose it specifies a real Recipient's participantID like the following example: 

etsi-actorid-tsl02640pis::rfc5322:emailaddr-one-rem-md-recipient@one -rem-md.domain.com 

The REM/BUSDOX Gateway receives the messages sent from the BUSDOX user and envelopes it in a standard MIME 
Message using, as Recipient, the following example address extracted from the Recipient's participantID: 

emailaddr-one-rem-md-recipient@one-rem-md.domain.com 

The REM/BUSDOX Gateway, will add also the following headers where, in the example, the first is the participantID 
of the Recipient and the second is the participantID of the Sender (this is needed to allow the Recipient eventual replies 
to the message) 

X-REM-Busdox-recipientId: etsi-actorid-tsl02640pis::rfc5322:emailaddr-one-rem-md-recipient@one-rem- 
md.domain.com 

X-REM-Busdox-senderId:busdox-actorid-upis::0010:5798000000001 

In Figure 5 there is example of this flow. 



BUSDOX Sender 



REM Recipient 





The recipient receives a 
REM-MD Message 



The REM-MD Gateway envelopes the BusDox message in a standard MiME Message using, as recipient, the example address: 
emailaddr-one-rem-md-recipient@one-rem-md.domain.coi extracted from the recipient's participantID 
The REM-MD Gateway, producing the MIME message for the REM Network, will compile the following headers: 
X-REM-Busdox-recipientld: etsi-actorid-ts102640pis::rfc5322:emailaddr-one-re m-md-recipient@one-rem-md.domain.com 
X-REM-Busdox-senderld: busdox-actorid-upis::001 0:5798000000001 



BusDox document sent, for example, to the following final recipient's ParticipantID of a REM user: 
etsi-actorid-ts102640pis::rfc5322:emailaddr-one-re m-md-recipient@one-rem-md.domain.com 



Figure 5 
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Alternatively the REM Recipient might not be registered to SMP with a specific participantlD. The REM/BUSDOX 
Gateway may act on behalf of such type of Recipients. The BUSDOX sender may specify, as virtual Recipient, a 
particular REM/BUSDOX Gateway participantlD (one of a set of 1..N participantlD associated to as many gateway 
mailboxes, for scalability purposes) of the gateway. E.g.: 

'etsi-actorid-tsl02640pis::rfc5322: rem-mdgatewayl@rem-md-gateway-domain' 

The BUSDOX sender specifies the standard email address of the Recipient in the "To:" header of MIME envelope. For 
example: 

emailaddr-one-rem-md-recipient@one-rem-md.domain.com 

The Sender specifies also the MIME headers "From:/Reply-to:" of the message to send with one of the following own 
values. For example: 

From: 5798000000001 @ rem- md-gateway-domain 

Reply -to: 5798000000001 @rem-md-gateway-domain 

The Sender should also specify the MIME headers for Sender's participantlD. In case of particular agreements this 
header may be added by the REM/BUSDOX Gateway, using the participantlD value present in the pure BUSDOX 
SOAP Envelop, as follows: 

X-REM-Busdox-senderId:busdox-actorid-upis::0010:5798000000001 

In Figure 6 there is example of this flow. 



BUSDOX Sender 



REM Recipient 




The recipient receives a 
REM-MD Message 




The REM-MD Gateway submits the BusDox MIME message leaving, as recipient, the address specified by the Sender. In this example 

address: dr-one-rem-md-recipienli_ i.domain.com 

In case of paflicular agreement, v^en the sender doesn't do this, the REM-MD Gateway may compiete the incoming MiME adding the 

foiloviflng header: 

X-REM-Busdox-senderld:busdox-actorld-upl5::0010:5798000000001 



BusDox MiME document sent, for example, to the foiiovwng REM-MD Gateway's ParticipantlD: 

etsl-actorlcHs102640pis::rfc5322:'-<?m-mdgateway1@rem-md-gateway-domain 

The MIME envelope contains the standard emaii address of the sender/recipient. For example: 

Fror 

Rep.j 

To: emailaddr-one-rem-md-recipient@one-rem-md.domain.com 



Figure 6 



It is important to outline that in this flow, is not necessary the REM Recipient to be registered to SMP. 

Some detailed example of this opposite (answer/reply) flow is defined in Figure 4. 

The first part of interaction flow (Sender - Sender's BUSDOX AP) shall be executed as usual in BUSDOX 
environment. After this step, the Sender's BUSDOX message shall be delivered to the Recipient's REM-MD (by means 
of cUent/server polling performed by REM/BUSDOX Gateway to the Recipient's BUSDOX AP) according to the LIME 
profile defined in the BUSDOX LIME Technical Specification [9]. 

The Recipient's REM-MD shall "forward" the incoming BUSDOX message to the intended REM Recipient, as usual in 
REM environment. 

The lookup on SML/SMP BUSDOX services, the LIME access, the generation of the REM-MD message and the 
Evidence relevant to the steps of the flow shall be defined in the next clauses. 
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7.3.1 SML and SMP Profiling 



In this scenario, the lookup of Service Metadata information shall be very similar to the opposite flow described in 
clause 7.2.2 of the present document. So even in this case the submission of a message through the Sender's BUSDOX 
AP requires the compilation of some parameters such as the identity and other Recipient's properties. And also as for 
the opposite scenario, every "participant" of the BUSDOX system (and therefore also every particular recipient like a 
REM-MD service, that in this case is a BUSDOX receiver entity) is recorded to one and only one SMP. 

Under these considerations the necessary sequence of steps that the Sender's BUSDOX application needs to implement 
shall be the following: 

• The Sender's BUSDOX application composes the access URL, to the SML in order to discover the access 
URL of the SMP provider for the specific Recipient, according to the Service Metadata Locator (SML) 
specification [8]. 

• The Sender's BUSDOX application requires to SMP the Service Metadata relevant to the Recipient of the 
REM-MD message using the URL composed according to the previous point. 

• The Sender's BUSDOX application, using the Service Metadata received from the SMP answer, compiles the 
correct BUSDOX message to submit to the AP. 

A detailed track of the steps summarized above is defined in the next clauses. 

7.3.1 .1 URL to access to SMP composition 

The composition of the URL to access to SMP is very similar to that defined in clause 7.2.2.1 but reversing the roles. 
Even in this case is not always necessary to for the REM Recipient to be registered to SMP but, in some case, the 
REM/BUSDOX Gateway may act on behalf of REM Recipients. 

The format of the URL for the lookup to SMP has the following syntax: 

http://<hash over recipient's participantID>.<schemeID>.<SML domain>/<recipient's 
participantID>/services/<documentType> 

Where: 

• The HASH of the Recipient's participantID is composed of the string "B-" followed by the MD5 hash of the 
participantID (the recipientID in this case). The purported Recipient's participant identifier shall be composed 
by the BUSDOX sender application as usual. It is out of the scope of the present document to specify how the 
BUSDOX sender may gain access to this information. 

• The schemelD shall be the scheme under which the Recipient's participantID has been generated . It is out of 
the scope of the present document to specify how the BUSDOX sender may gain access to this information. 

• The SML internet domain is a fixed starting domain that shall be available for BUSDOX sender application. It 
is out of the scope of the present document to specify how the BUSDOX sender application may gain access to 
this information. 

• An appropriate document type shall be used according to the type of document to send and with the definitions 
of clause 7. L L2. It is out of the scope of the present document to deal with the means by which the Sender 
may gain access to the document types that the Recipient may deal with. 

The present document does not provide further profiling of BUSDOX Service Metadata Locator (SML) 
specification [8]. 
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This is a non-normative example text explaining a possible composition of the URL to access to SMP. 

To send a message from a BUSDOX sender to a REM Recipient identified by the following Participant Identifier 

<full Recipient's participantID> = "etsi-actorid-tsl02640pis : :rfc5322 :emailaddr-one-rem-md- 
recipient@one-rem-md.domain.com" {Full scheme-id + Type/Val) 

the BUSDOX sender application needs to compose the URL to access to SMP with the following format: 

http://<hash over recipientID> . <schemeID> . <SML domain>/<recipientID>/services/<documentType> 

using the following fields: 

<hash Recipient's participantID type/value part> = "B- "md5 { "rf c5322 : emailaddr-one-rem-md- 
recipient@one-rem-md.domain.com") = "B-f 5b77e050c0 52c88d77c2b0acc6851f 7" 



<schemeID> 



"etsi-actorid-tsl02 64 0pis" 



<SML domain> = "serviceMetadata . eu" {This is an example for SML internet domain address configured 
in the BUSDOX sender application) 

<Recipient's participantID> = "rfc5322 :emailaddr-one-rem-md-recipient@one-rem-md. domain. com" 

{Type/Val) 



<documentType> 



"etsi-docid-tsl02 64 0dis : :rfc5751 :mime" 



SO one of the URL that BUSDOX sender application may use for the SMP discovery, for this example is: 

http://B-f5b77e0 5 0c0 52c8 8d77c2b0acc6 8 51f7.etsi-actorid- 

tsl02G4 0pis. serviceMetadata . eu/busdoxdomain. eu/etsi-actorid-tsl02 64 0pis : : rf c5 322 : emailaddr-one-rem- 

md-recipient@one-rem-md. domain. com/services/etsi-docid-tsl02 64 0dis : : rf c5 751 :mime 

Due to reserved words the URL above needs to be percent encoded to be compliant with the specification "Uniform 
Resource Identifier (URI): Generic Syntax" (RFC 3986 [i.6]), as required in the Service Metadata Publishing Technical 
Specification 7] (where a full description of discovery process may be found), and it becomes: 

http://B-f5b77e0 50c0 52c88d77c2b0acc6851f7.etsi-actorid- 

tsl02640pis . serviceMetadata . eu/busdoxdomain . eu/etsi-actorid-tsl02640pis%3A%3Arf c5322%3Aemailaddr- 

one-rem-md-recipient%4 Done -rem-md. domain. com/services/etsi-docid-tsl02 64 0dis%3A%3Arf c5 751%3Amime 



7.3.1.2 



REM-MD Service Metadata store to SMP 



The present document profiles new types of contents for the Servicelnformation element specified in SMP Technical 
Specification [7], namely the one that associates the REM-MD interacting with a BUSDOX instantiation Access Point 
with the document type identifier defined in clause 7.1.1.2. 

Table 6 specifies the contents of such new Servicelnformation element. 

Table 6: Metadata Service information 



Element/attribute 


Mandatory/Optional 


Number of 
occurrences 


Additional Requirements 


Participant Identifier 


M 


1 


Participant identifier value aligned with the 
format specified in clause 7.1 .1 .L 


Participant Identifier/ 
©scheme 


M 


1 


Participant identifier scheme aligned with 
definition specified in clause 7.1 .1 .1 . 


Document Identifier 


M 


1 


Document identifier aligned with 
definitions specified in clause 7.1 .1 .2 and 
in Table 3. 


Document Identifier/ 
©scheme 


M 


1 


Document identifier scheme aligned with 
definitions specified in clause 7.1 .1 .2 and 
in Table 3. 



7.3.1.3 



Service Metadata Retrieval from SMP 



Using the URL composed as specified in the previous section the Service Metadata for a specified Recipient may be 
retrieved accessing to the pointed SMP exactly as per the opposite scenario defined in clause 7.2.2.2. 
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7.3.1 .4 BUSDOX Headers and REM Headers/Metadata 

In this scenario the same headers of the opposite scenario defined in clause 7.2.2.3 shall be used. 

7.3.2 LIME Profile 

The BUSDOX sender appHcation shall acts as usually in BUSDOX network. It is out of the scope of the present 
document to specify how this application interacts with a BUSDOX Access Point and if this interaction is according to 
the LIME profile. 

7.3.3 Generating REM-MD message 

Even in this case the REM-MD messages shall be generated only at REM-MD level and the same considerations of the 
opposite scenario defined in clause 7.2.5 shall be valid. It is out of the scope of the present document to specify how the 
BUSDOX sender generates, when required, a standard MIME message to attach as Sender's payload to the usual 
BUSDOX message. 

7.3.4 Evidence 

In this scenario it is possible leverage the Evidence Layer of REM network to add some other tracking information to 
the BUSDOX sender. All the mandatory Evidence types present in Table 7, generated from the Recipient's REM-MD, 
may be forwarded back to the BUSDOX sender. Furthermore some other optional Evidence may be requested and so 
forwarded as the others. The actor of these operations is the REM/BUSDOX Gateway that shall implement some 
behaviour regarding the Evidence handling according to some service policy agreed with the parts. 

Table 7: Evidence types list for BUSDOX-REM scenario 



Event and REM-MD Evidence 
(TS 102 640-1 [1], clause 6.1) 


REM-MD Evidence 
(TS 102 640-2 [2], clause 5.1) 


6.2.1 Event A.I - S-REM-MD Acceptance 


5.1 .1 SubmissionAcceptanceRejection 


6.2.1 Event A.2 - S-REM-MD Rejection 


6.2.2 Event B.I - R-REM-MD Acceptance 


5.1 .2 Relay ToREMMDAcceptanceRejection 


6.2.2 Event B.2 - R-REM-MD Rejection 


6.2.2 Event B.3 - Expiration of time to deliver to R-REM-MD 


5.1.3 RelayloREMMDFailure 


6.2.3 Event C.I - REM Object Delivery 


5.1 .4 DeliveryNonDeliveryToRecipient 


6.2.3 Event C.2 - Non delivery within a given retention period 


6.2.3 Event D.I - REM-MD Message Delivery 


6.2.3 Event D.2 - Expiration of time to deliver notification 


6.2.3 Event F.I (mailbox) - Retrieval 


5.1 .6 RetrievalNonRetrievalByRecipient 


6.2.3 Event F.2 (mailbox) - Expiration of time for Retrieval 



All the mandatory/Recommended/Optional evidence types present in the Table 7 above may be forwarded back to the 
BUSDOX sender, each in a new BUSDOX message, by the REM/BUSDOX Gateway using a similar flow of that 
defined for answers/replies. This means that the REM/BUSDOX Gateway, according to the local policy agreements, 
shall autonomously compose new BUSDOX messages for the Sender containing the evidence messages coming from 
the REM-MD. A similar back answer/reply flow is defined in clause 7.3 and some non-normative example may be 
found in Figure 5 and Figure 6. It is out of the scope of the present document to specify how the REM/BUSDOX 
Gateway maintains the necessary mappings among the addresses present in Evidence messages and BUSDOX 
addresses who to forward the Evidence. 

In particular, the SubmissionAcceptanceRejection evidence shall be sent also to the Recipient (attached to the REM- 
MD Message) but in this case it is, for the Recipient, somehow weaker than the same evidence in REM pure network. 
In fact a SubmissionAcceptanceRejection evidence is normally produced (and signed) by the Sender's REM-MD 
whereas, in this scenario, it is generated from the Recipient's REM-MD. 
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